The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals. The Session Description Protocol (SDP), carried by SIP signals, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a General Packet Radio Service (GPRS) access network. As shown in FIG. 1a control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer plane and through which signals are directed to/from user equipment (UE) accessing the network. The entities within the connectivity layer 1 that connect an IMS subscriber to IMS services form a network that is referred to as the IP-Connectivity Access Network, IP-CAN. The GPRS network includes various GPRS Support Nodes (GSNs). A gateway GPRS support node (GGSN) 2 acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). The middle layer is the Control Layer 4, and at the top is the Application Layer 6.
The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5, which operate as SIP proxies within the IMS in the middle, Control Layer 4. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. The top, Application Layer 6 includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality.
When an emergency call is placed using a UE, it is normally routed from the P-CSCF to and Emergency CSCF (E-CSCF). The E-CSCF is concerned only with handling emergency calls. The E-CSCF must determine the most appropriate Public Safety Answering Point (PSAP), for example the nearest emergency services call centre, and forwards emergency INVITE messages to the PSAP. The E-CSCF is attached to a Location Retrieval Function (LRF), which allows it to determine the location of the calling UE.
In some circumstance it may be necessary to route an emergency call via the S-CSCF. This is the case where, for example, a security association has not been established between the P-CSCF and the UE at registration, and the local emergency authorities do not accept emergency calls that have not been authenticated. This is discussed in 3GPP TSG-SA WG2 S2-095075. Where there is no security association, the S-CSCF performs a SIP-digest authentication for every dialogue. The Emergency session is therefore sent via the S-CSCF, which queries the UE's credentials. Another scenario in which the emergency call might be routed via the S-CSCF is where either the S-CSCF or an AS needs to perform a further number analysis. An example of this is a large corporation that has their own emergency response procedures. In this case, the corporation may choose to re-route a call to a public emergency number such as 112 to their own emergency centre before contacting the appropriate PSAP.
This solution to allowing a UE that has not established a security association with the P-CSCF works in most network scenarios. However, it will not work in a network that handles both fixed and mobile users, because for mobile users using such a network, direct routing is needed to the E-CSCF, in particular for those cases where the user is roaming (due, in part, to regulatory and liability issues). Furthermore, routing emergency sessions via the S-CSCF is not optimal in the case of a fixed access user that is already authenticated, as it requires additional proxy nodes in the path, that during an emergency situation may become a bottle neck that can become overloaded if many users are trying to access the emergency ser vices (as it in general serves many more users than a P-CSCF).